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Abstract 


This document specifies a solution for the delivery of IPv4 multicast 
services to IPv4 clients over an IPv6 multicast network. The 
solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme 
and uses an IPv6 multicast distribution tree to deliver IPv4 
multicast traffic. The solution is particularly useful for the 
delivery of multicast service offerings to customers serviced by 
Dual-Stack Lite (DS-Lite). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8114. 
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1. Introduction 


DS-Lite [RFC6333] is an IPv4 address-sharing technique that enables 
operators to multiplex public IPv4 addresses while provisioning only 
IPv6 to users. A typical DS-Lite scenario is the delivery of an IPv4 
service to an IPv4 user over an IPv6 network (denoted as a 4-6-4 
scenario). [RFC6333] covers unicast services exclusively. 


This document specifies a generic solution for the delivery of IPv4 
multicast services to IPv4 clients over an IPv6 multicast network. 
The solution was developed with DS-Lite in mind (see more discussion 
below). However, the solution is not limited to DS-Lite; it can also 
be applied in other deployment contexts, such as the ones described 
in [RFC7596] and [RFC7597]. 


If customers have to access IPv4 multicast-based services through a 
DS-Lite environment, Address Family Transition Router (AFTR) devices 
will have to process all the Internet Group Management Protocol 
(IGMP) Report messages [RFC2236] [RFC3376] that have been forwarded 
by the Customer Premises Equipment (CPE) into the IPv4-in-IPv6 
tunnels. From that standpoint, AFTR devices are likely to behave as 
a replication point for downstream multicast traffic, and the 
multicast packets will be replicated for each tunnel endpoint that 
IPv4 receivers are connected to. 


This kind of DS-Lite environment raises two major issues: 


1. The IPv6 network loses the benefits of efficient multicast 
traffic forwarding because it is unable to deterministically 
replicate the data as close to the receivers as possible. Asa 
consequence, the downstream bandwidth in the IPv6 network will be 
vastly consumed by sending multicast data over a unicast 
infrastructure. 


2. The AFTR is responsible for replicating multicast traffic and 
forwarding it into each tunnel endpoint connecting IPv4 receivers 
that have explicitly asked for the corresponding content. This 
process may significantly consume the AFTR’s resources and 
overload the AFTR. 


This document specifies an extension to the DS-Lite model to deliver 


IPv4 multicast services to IPv4 clients over an IPv6 multicast- 
enabled network. 
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This document describes a stateless translation mechanism that 
supports either Source-Specific Multicast (SSM) or Any-Source 
Multicast (ASM) operation. The recommendation in Section 1 of 
[RFC4607] is that multicast services use SSM where possible; the 
operation of the translation mechanism is also simplified when SSM is 
used, e.g., considerations for placement of the IPv6 Rendezvous Point 
(RP) are no longer relevant. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Terminology 
This document makes use of the following terms: 


IPv4-embedded IPv6 address: an IPv6 address that embeds a 32-bit- 
encoded IPv4 address. An IPv4-embedded IPv6 address can be 
unicast or multicast. 


mPrefix64: a dedicated multicast IPv6 prefix for constructing 
IPv4-embedded IPv6 multicast addresses. mPrefix64 can be of two 
types: ASM_mPrefix64 used in Any-Source Multicast (ASM) mode or 
SSM_mPrefix64 used in Source-Specific Multicast (SSM) mode 
[RFC4607]. The size of this prefix is /96. 


Note: "64" is used as an abbreviation for IPv6-IPv4 
interconnection. 


uPrefix64: a dedicated IPv6 unicast prefix for constructing 
IPv4-embedded IPv6 unicast addresses [RFC6052]. This prefix may 
be either the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network- 
Specific Prefix (NSP). 


Multicast AFTR (mAFTR): a functional entity that supports an 
IPv4-IPv6 multicast interworking function (refer to Figure 3). It 
receives and encapsulates the IPv4 multicast packets into IPv4-in- 
IPv6 packets. Also, it behaves as the corresponding IPv6 
multicast source for the encapsulated IPv4-in-IPv6 packets. 


Multicast Basic Bridging BroadBand (mB4): a functional entity that 
supports an IGMP-MLD Interworking function (refer to Section 6.1) 
that translates the IGMP messages into the corresponding Multicast 
Listener Discovery (MLD) messages and sends the MLD messages to 
the IPv6 network. In addition, the mB4 decapsulates IPv4-in-IPv6 
multicast packets. 
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PIMv4: refers to Protocol Independent Multicast (PIM) when deployed 
in an IPv4 infrastructure (i.e., IPv4 transport capabilities are 
used to exchange PIM messages). 


PIMv6: refers to PIM when deployed in an IPv6 infrastructure (i.e., 
IPv6 transport capabilities are used to exchange PIM messages) . 


Host portion of the MLD protocol: refers to the part of MLD that 
applies to all multicast address listeners (Section 6 of 
[RFC3810]). As a reminder, MLD specifies separate behaviors for 
multicast address listeners (i.e., hosts or routers that listen to 
multicast packets) and multicast routers. 


Router portion of IGMP: refers to the part of IGMP that is performed 
by multicast routers (Section 6 of [RFC3376]). 


DR: refers to the Designated Router as defined in [RFC7761]. 
3. Scope 


This document focuses only on the subscription to IPv4 multicast 
groups and the delivery of IPv4-formatted content to IPv4 receivers 
over an IPv6-only network. In particular, only the following case is 
covered: 


IPv4 receivers access IPv4 multicast content over IPv6-only 
multicast-enabled networks. 


This document does not cover the source/receiver heuristics, where 
IPv4 receivers can also behave as IPv4 multicast sources. This 
document assumes that hosts behind the mB4 are IPv4 multicast 
receivers only. Also, the document covers the host built-in mB4 
function. 


4. Solution Overview 


In the DS-Lite specification [RFC6333], an IPv4-in-IPv6 tunnel is 
used to carry bidirectional IPv4 unicast traffic between a B4 and an 
AFTR. The solution specified in this document provides an IPv4-in- 
IPv6 encapsulation scheme to deliver unidirectional IPv4 multicast 
traffic from an mAFTR to an mB4. 


An overview of the solution is provided in this section; it is 
intended as an introduction to how it works but is not normative. 
For the normative specifications of the two new functional elements, 
mB4 and mAFTR (Figure 1), refer to Sections 6 and 7. 
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Figure 1: Functional Architecture 
4.1. IPv4-Embedded IPv6 Prefixes 


In order to map the addresses of IPv4 multicast traffic with IPv6 
multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 
unicast prefix (uPrefix64) are provided to the mAFTR and the mB4 
elements, both of which contribute to the computation and the 
maintenance of the IPv6 multicast distribution tree that extends the 
IPv4 multicast distribution tree into the IPv6 multicast network. 

The IPv4/IPv6 address mapping is stateless. 


The mAFTR and the mB4 use mPrefix64 to convert an IPv4 multicast 
address (G4) into an IPv4-embedded IPv6 multicast address (G6). The 
mAFTR and the mB4 use uPrefix64 to convert an IPv4 source address 
(S4) into an IPv4-embedded IPv6 address (S6). The mAFTR and the mB4 
must use the same mPrefix64 and uPrefix64; they also run the same 
algorithm for building IPv4-embedded IPv6 addresses. Refer to 
Section 5 for more details about the address mapping. 
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4.2. Multicast Distribution Tree Computation 


When an IPv4 receiver connected to the device that embeds the mB4 
capability wants to subscribe to an IPv4 multicast group, it sends an 
IGMP Report message towards the mB4. The mB4 creates the IPv6 
multicast group (G6) address using mPrefix64 and the original IPv4 
multicast group address. If the receiver sends a source-specific 
IGMPv3 Report message, the mB4 will create the IPv6 source address 
(S6) using uPrefix64 and the original IPv4 source address. 


The mB4 uses the G6 (and both S6 and G6 in SSM) to create the 
corresponding MLD Report message. The mB4 sends the Report message 
towards the IPv6 network. The PIMv6 DR receives the MLD Report 
message and sends the PIMv6 Join message to join the IPv6 multicast 
distribution tree. It can send either PIMv6 Join (*,G6) in ASM or 
PIMv6 Join (S6,G6) in SSM to the mAFTR. 


The mAFTR acts as the IPv6 DR to which the uPrefix64-derived S6 is 
connected. The mAFTR will receive the source-specific PIMv6 Join 
message (S6,G6) from the IPv6 multicast network. If the mAFTR is the 
Rendezvous Point (RP) of G6, it will receive the any-source PIMv6 
Join message (*,G6) from the IPv6 multicast network. If the mAFTR is 
not the RP of G6, it will send the PIM Register message to the RP of 
G6 located in the IPv6 multicast network. For the sake of 
simplicity, it is recommended to configure the mAFTR as the RP for 
the IPv4-embedded IPv6 multicast groups it manages; no registration 
procedure is required under this configuration. 


When the mAFTR receives the PIMv6 Join message (*,G6), it will 
extract the IPv4 multicast group address (G4). If the mAFTR is the 
RP of G4 in the IPv4 multicast network, it will create a (*,G4) entry 
(if such entry does not already exist) in its own IPv4 multicast 
routing table. If the mAFTR is not the RP of G4, it will send the 
corresponding PIMv4 Join message (*,G4) towards the RP of G4 in the 
IPv4 multicast network. 


When the mAFTR receives the PIMv6 Join message (S6,G6), it will 
extract the IPv4 multicast group address (G4) and IPv4 source address 
(S4) and send the corresponding (S4,G4) PIMv4 Join message directly 
to the IPv4 source. 


A branch of the multicast distribution tree is thus constructed, 
comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 
part (from mAFTR downstream towards the mB4). 


The mAFTR advertises the route of uPrefix64 with an IPv6 Interior 


Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6 
source in the IPv6 multicast network and to allow IPv6 routers to run 
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the Reverse Path Forwarding (RPF) check procedure on incoming 
multicast traffic. Injecting internal /96 routes is not problematic 
given the recommendation in [RFC7608] that requires that forwarding 
processes must be designed to process prefixes of any length up to 
/128. 


4.3. Multicast Data Forwarding 


When the mAFTR receives an IPv4 multicast packet, it will encapsulate 
the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 
multicast address as the destination address and an IPv4-embedded 
IPv6 unicast address as the source address. The encapsulated IPv6 
multicast packet will be forwarded down the IPv6 multicast 
distribution tree, and the mB4 will eventually receive the packet. 


The IPv6 multicast network treats the IPv4-in-IPv6 encapsulated 


multicast packets as native IPv6 multicast packets. The IPv6 
multicast routers use the outer IPv6 header to make their forwarding 
decisions. 


When the mB4 receives the IPv6 multicast packet (to G6) derived by 
mPrefix64, it decapsulates it and forwards the original IPv4 
multicast packet towards the receivers subscribing to G4. 


Note: At this point, only IPv4-in-IPv6 encapsulation is defined; 
however, other types of encapsulation could be defined in the future. 


5. IPv4/IPv6 Address Mapping 
5.1. Prefix Assignment 


A dedicated IPv6é multicast prefix (mPrefix64) is provisioned to the 
mAFTR and the mB4. The mAFTR and the mB4 use the mPrefix64 to form 
an IPv6 multicast group address from an IPv4 multicast group address. 
The mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used 
in ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode). The 
mPrefix64 MUST be derived from the corresponding IPv6 multicast 
address space (e.g., the SSM_mPrefix64 must be in the range of the 
multicast address space specified in [RFC4607]). 


The IPv6 part of the multicast distribution tree can be seen as an 
extension of the IPv4 part of the multicast distribution tree. The 
IPv4 source address MUST be mapped to an IPv6 source address. An 
IPv6 unicast prefix (uPrefix64) is provisioned to the mAFTR and the 
mB4. The mAFTR and the mB4 use the uPrefix64 to form an IPv6 source 
address from an IPv4 source address as specified in [RFC6052]. The 
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uPrefix-formed IPv6 source address will represent the original IPv4 
source in the IPv6 multicast network. The uPrefix64 MUST be derived 
from the IPv6 unicast address space. 


The multicast address translation MUST follow the algorithm defined 
in Section 5.2. 


The mPrefix64 and uPrefix64 can be configured in the mB4 using a 
variety of methods, including an out-of-band mechanism, manual 
configuration, or a dedicated provisioning protocol (e.g., using 
DHCPv6 [RFC8115]). 


The stateless translation mechanism described in Section 5 does not 
preclude use of Embedded-RP [RFC3956] [RFC7371]. 


5.2. Multicast Address Translation Algorithm 


IPv4-embedded IPv6 multicast addresses are composed according to the 
following algorithm: 


o Concatenate the 96 bits of the mPrefix64 and the 32 bits of the 
IPv4 address to obtain a 128-bit address. 


The IPv4 multicast addresses are extracted from the IPv4-embedded 
IPv6 multicast addresses according to the following algorithm: 


o If the multicast address has a pre-configured mPrefix64, extract 
the last 32 bits of the IPv6 multicast address. 


An IPv4 source is represented in the IPv6 realm with its 
IPv4-converted IPv6 address [RFC6052]. 


5.3. Textual Representation 


The embedded IPv4 address in an IPv6 multicast address is included in 
the last 32 bits; therefore, dotted decimal notation can be used. 


5.4. Examples 
Group address mapping example: 


4--------------------- 4+-------------- + 

| mPrefix64 | | 

4+--------------------- 4+-------------- 4---------------------------- + 
| | 
+ + 


| ff0x::db8:0:0/96 
+ A A ee ee ee et 
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6. 


6. 


Source address mapping example when a /96 is used: 


IPv4 and IPv6 addresses used in this example are derived from the 
IPv4 and IPv6 blocks reserved for documentation, as per [RFC6676]. 
The unicast IPv4 address of the above example is derived from the 
documentation address block defined in [RFC6890]. 


Multicast B4 (mB4) 
1. IGMP-MLD Interworking Function 


The IGMP-MLD Interworking function combines the IGMP/MLD Proxying 
function and the address-synthesizing operations. The IGMP/MLD 
Proxying function is specified in [RFC4605]. The address translation 
is stateless and MUST follow the address mapping specified in 

Section 5. 


The mB4 performs the host portion of the MLD protocol on the upstream 
interface. The composition of IPv6 membership in this context is 
constructed through address-synthesizing operations and MUST 
synchronize with the membership database maintained in the IGMP 
domain. MLD messages are sent natively to the direct-connected IPv6 


multicast routers (they will be processed by the PIM DR). The mB4 
also performs the router portion of IGMP on the downstream 
interface(s). Refer to [RFC4605] for more details. 
+---------- + IGMP +------- + MLD +--------- + 
IPv4  |--------- mB4 = |--------- PIM 
Receiver DR 
4+---------- + +------- + Ho + 


Figure 2: IGMP-MLD Interworking 


If SSM is deployed, the mB4 MUST construct the IPv6 source address 
(or retrieve the IPv4 source address) using the uPrefix64. The mB4 
MAY create a membership database that associates the IPv4-IPv6 
multicast groups with the interfaces (e.g., WLAN and Wired Ethernet) 
facing IPv4 multicast receivers. 
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6.2. Multicast Data Forwarding 


When the mB4 receives an IPv6 multicast packet, it MUST check the 
group address and the source address. If the IPv6 multicast group 
prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4 
MUST decapsulate the IPv6 header [RFC2473]; the decapsulated IPv4 
multicast packet will be forwarded through each relevant interface 
following standard IPv4 multicast forwarding procedures. Otherwise, 
the mB4 MUST silently drop the packet. 


As an illustration, if a packet is received from source 
2001:db8::192.0.2.33 and needs to be forwarded to group 
ff3x:20:2001:db8::233.252.0.1, the mB4 decapsulates it into an IPv4 
multicast packet using 192.0.2.33 as the IPv4 source address and 
using 233.252.0.1 as the IPv4 destination multicast group. This 
example assumes that the mB4 is provisioned with uPrefix64 
(2001:db8::/96) and mPrefix64 (ff3x:20:2001:db8::/96). 


6.3. Fragmentation 


Encapsulating IPv4 multicast packets into IPv6 multicast packets that 
will be forwarded by the mAFTR towards the mB4 along the IPv6 
multicast distribution tree reduces the effective MTU size by the 
size of an IPv6 header. In this specification, the data flow is 
unidirectional from the mAFTR to the mB4. The mAFTR MUST fragment 
the oversized IPv6 packet after the encapsulation into two IPv6 
packets. The mB4 MUST reassemble the IPv6 packets, decapsulate the 
IPv6 header, and forward the IPv4 packet to the hosts that have 
subscribed to the corresponding multicast group. Further 
considerations about fragmentation issues are documented in Sections 
5.3 and 6.3 of [RFC6333]. 


6.4. Host Built-In mB4 Function 


If the mB4 function is implemented in the host that is directly 
connected to an IPv6-only network, the host MUST implement the 
behaviors specified in Sections 6.1, 6.2, and 6.3. The host MAY 
optimize the implementation to provide an Application Programming 
Interface (API) or kernel module to skip the IGMP-MLD Interworking 
function. Optimization considerations are out of scope of this 
specification. 
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6.5. Preserve the Scope 


When several mPrefix64s are available, if each enclosed IPv4-embedded 
IPv6 multicast prefix has a distinct scope, the mB4 MUST select the 
appropriate IPv4-embedded IPv6 multicast prefix whose scope matches 
the IPv4 multicast address used to synthesize an IPv4-embedded IPv6 
multicast address (specific mappings are listed in Section 8 of 
[RFC2365]). Mapping is achieved such that the scope of the selected 
IPv6 multicast prefix does not exceed the original IPv4 multicast 
scope. If the mB4 is instructed to preserve the scope but no IPv6 
multicast prefix that matches the IPv4 multicast scope is found, IPv6 
multicast address mapping SHOULD fail. 


The mB4 MAY be configured to not preserve the scope when enforcing 
the address translation algorithm. 


Consider that an mB4 is configured with two mPrefix64s, 
ff0e::db8:0:0/96 (global scope) and ff08::db8:0:0/96 (organization 
scope). If the mB4 receives an IGMP Report message from an IPv4 
receiver to subscribe to 233.252.0.1, it checks which mPrefix64 to 
use in order to preserve the scope of the requested IPv4 multicast 
group. In this example, given that 233.252.0.1 is intended for 
global use, the mB4 creates the IPv6 multicast group (G6) address 
using ff0e::db8:0:0/96 and the original IPv4 multicast group address 
(233::2927+0% 1) 2 EE08*:0db83233:2092% Oiéiles 


7. Multicast AFTR (mAFTR) 
7.1. Routing Considerations 


The mAFTR is responsible for interconnecting the IPv4 multicast 
distribution tree with the corresponding IPv6 multicast distribution 
tree. The mAFTR MUST use the uPrefix64 to build the IPv6 source 
addresses of the multicast group address derived from mPrefix64. In 
other words, the mAFTR MUST be the multicast source whose address is 
derived from uPrefix64. 


The mAFTR MUST advertise the route towards uPrefix64 with the IPv6 


IGP. This is needed by the IPv6 multicast routers so that they 
acquire the routing information to discover the source. 
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7.2. Processing PIM Messages 


The mAFTR MUST interwork PIM Join/Prune messages for (*,G6) and 


(S6,G6) on their corresponding (*,G4) and (S4,G4). The following 
text specifies the expected behavior of the mAFTR for PIM Join 
messages. 

+--------- + 

Lo MAFTR  |--------- 
PIMv6 uPrefix64 PIMv4 
|mPrefix64 | 
Ho + 


Figure 3: PIMv6-PIMv4 Interworking Function 


The mAFTR contains two separate Tree Information Bases (TIBs): the 
IPv4 Tree Information Base (TIB4) and the IPv6 Tree Information Base 
(TIB6), which are bridged by one IPv4-in-IPv6 virtual interface. It 
should be noted that TIB implementations may vary (e.g., some may 
rely upon a single integrated TIB without any virtual interface), but 
they should follow this specification for the sake of global and 
functional consistency. 


When an mAFTR receives a PIMv6 Join message (*,G6) with an IPv6 
multicast group address (G6) that is derived from the mPrefix64, it 
MUST check its IPv6 Tree Information Base (TIB6). If there is an 
entry for this G6 address, it MUST check whether the interface 
through which the PIMv6 Join message has been received is in the 
outgoing interface (oif) list. If not, the mAFTR MUST add the 
interface to the oif list. If there is no entry in the TIB6, the 
mAFTR MUST create a new entry (*,G6) for the multicast group. 
Whether or not the IPv4-in-IPv6 virtual interface is set as the 
incoming interface of the newly created entry is up to the 
implementation, but it should comply with the mAFTR’s multicast data 
forwarding behavior (see Section 7.4). 


The mAFTR MUST extract the IPv4 multicast group address (G4) from the 
IPv4-embedded IPv6 multicast address (G6) contained in the PIMv6 Join 
message. The mAFTR MUST check its IPv4 Tree Information Base (TIB4). 
If there is an entry for G4, it MUST check whether the IPv4-in-IPv6 
virtual interface is in the outgoing interface list. If not, the 
mAFTR MUST add the interface to the oif list. If there is no entry 
for G4, the mAFTR MUST create a new (*,G4) entry in its TIB4 and 
initiate the procedure for building the shared tree in the IPv4 
multicast network without any additional requirement. 
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If the mAFTR receives a source-specific Join message, the (S6,G6) is 


processed rather than (*,G6). The procedures of processing (S6,G6) 
and (*,G6) are almost the same. Differences have been detailed in 
[RFC7761]. 


7.3. Switching from Shared Tree to Shortest Path Tree 


When the mAFTR receives the first IPv4 multicast packet, it may 
extract the source address (S4) from the packet and send an Explicit 
PIMv4 (S4,G4) Join message directly to S4. The mAFTR switches from 
the shared Rendezvous Point Tree (RPT) to the Shortest Path Tree 
(SPT) for G4. 


For IPv6 multicast routers to switch to the SPT, there is no new 
requirement. IPv6é multicast routers may send an Explicit PIMv6 Join 
to the mAFTR once the first (S6,G6) multicast packet arrives from 
upstream multicast routers. 


7.4. Multicast Data Forwarding 


When the mAFTR receives an IPv4 multicast packet, it checks its TIB4 
to find a matching entry and then forwards the packet to the 
interface(s) listed in the outgoing interface list. If the IPv4-in- 
IPv6 virtual interface also belongs to this list, the packet is 
encapsulated with the mPrefix64-derived and uPrefix64-derived 
IPv4-embedded IPv6 addresses to form an IPv6 multicast packet 
[RFC2473]. Then another lookup is made by the mAFTR to find a 
matching entry in the TIB6. Whether or not the RPF check for the 
second lookup is performed is up to the implementation and is out of 
the scope of this document. The IPv6 multicast packet is then 
forwarded along the IPv6 multicast distribution tree, based upon the 
outgoing interface list of the matching entry in the TIB6. 


As an illustration, if a packet is received from source 192.0.2.33 
and needs to be forwarded to group 233.252.0.1, the mAFTR 
encapsulates it into an IPv6 multicast packet using 
ff3x:20:2001:db8::233.252.0.1 as the IPv6 destination multicast group 
and using 2001:db8::192.0.2.33 as the IPv6 source address. 


7.5. Scope 
The Scope field of IPv4-in-IPv6 multicast addresses should be valued 
accordingly (e.g., to "E" for global scope) in the deployment 
environment. This specification does not discuss the scope value 


that should be used. 


The considerations in Section 6.5 are to be followed by the mAFTR. 
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8. Deployment Considerations 
8.1. Other Operational Modes 
8.1.1. The IPv6 DR is Co-located with the mAFTR 


The mAFTR can embed the MLD Querier function (as well as the PIMv6 
DR) for optimization purposes. When the mB4 sends an MLD Report 
message to this mAFTR, the mAFTR should process the MLD Report 
message that contains the IPv4-embedded IPv6 multicast group address 
and then send the corresponding PIMv4 Join message (Figure 4). 


oo | MAFTR  |--------- 
MLD |uPrefix64| PIMv4 
|mPrefix64 | 


Figure 4: MLD-PIMv4 Interworking Function 


Discussions about the location of the mAFTR capability and related 
ASM or SSM multicast design considerations are out of the scope of 
this document. 


8.1.2. The IPv4 DR is Co-located with the mAFTR 
If the mAFTR is co-located with the IPv4 DR connected to the original 
IPv4 source, it may simply use the uPrefix64 and mPrefix64 prefixes 


to build the IPv4-embedded IPv6 multicast packets, and the sending of 
PIMv4 Join messages becomes unnecessary. 


8.2. Load Balancing 
For robustness and load distribution purposes, several nodes in the 
network can embed the mAFTR function. In such case, the same IPv6 
prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to build 
IPv4-embedded IPv6 addresses must be configured on those nodes. 


8.3. mAFTR Policy Configuration 


The mAFTR may be configured with a list of IPv4 multicast groups and 


sources. Only multicast flows bound to the configured addresses 
should be handled by the mAFTR. Otherwise, packets are silently 
dropped. 
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8. 


9. 


10. 


4. Static vs. Dynamic PIM Triggering 


To optimize the usage of network resources in current deployments, 
all multicast streams are conveyed in the core network while only the 
most popular ones are forwarded in the aggregation/access networks 
(static mode). Less popular streams are forwarded in the access 
network upon request (dynamic mode). Depending on the location of 
the mAFTR in the network, two modes can be envisaged: static and 
dynamic. 


Static Mode: The mAFTR is configured to instantiate permanent 
(S6,G6) and (*,G6) entries in its TIB6 using a pre-configured 
(S4,G4) list. 


Dynamic Mode: The instantiation or withdrawal of (S6,G6) or (*,G6) 
entries is triggered by the receipt of PIMv6 messages. 


Security Considerations 


Besides multicast scoping considerations (see Sections 6.5 and 7.5), 
this document does not introduce any new security concerns in 
addition to those discussed in Section 5 of [RFC6052], Section 10 of 
[RFC3810], and Section 6 of [RFC7761]. 


Unlike solutions that map IPv4 multicast flows to IPv6 unicast flows, 
this document does not exacerbate Denial-of-Service (DoS) attacks. 


An mB4 SHOULD be provided with appropriate configuration information 
to preserve the scope of a multicast message when mapping an IPv4 
multicast address into an IPv4-embedded IPv6 multicast address and 
vice versa. 


1. Firewall Configuration 
The CPE that embeds the mB4 function SHOULD be configured to accept 


incoming MLD messages and traffic forwarded to multicast groups 
subscribed to by receivers located in the customer premises. 


IANA Considerations 


This document does not require any IANA actions. 
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Appendix A. Use Case: IPTV 
IPTV generally includes two categories of service offerings: 


o Video on Demand (VoD) that streams unicast video content to 
receivers. 


o Multicast live TV broadcast services. 
Two types of provider are involved in the delivery of this service: 


o Content Providers, who usually own the content that is multicast 
to receivers. Content providers may contractually define an 
agreement with network providers to deliver content to receivers. 


o Network Providers, who provide network connectivity services 
(e.g., network providers are responsible for carrying multicast 
flows from head-ends to receivers). 


Note that some contract agreements prevent a network provider from 
altering the content as sent by the content provider for various 
reasons. Depending on these contract agreements, multicast streams 
should be delivered unaltered to the requesting users. 


Most current IPTV content is likely to remain IPv4-formatted and out 
of the control of network providers. Additionally, there are 
numerous legacy receivers (e.g., IPv4-only Set-Top Boxes (STBs)) that 
can’t be upgraded or easily replaced to support IPv6. Asa 
consequence, IPv4 service continuity must be guaranteed during the 
transition period, including the delivery of multicast services such 
as Live TV Broadcasting to users. 
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Appendix B. Older Versions of Group Membership Management Protocols 


Given the multiple versions of group membership management protocols, 
mismatch issues may arise at the mB4 (refer to Section 6.1). 


If IGMPv2 operates on the IPv4 receivers while MLDv2 operates on the 
MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1 
operates on the MLD Querier, a version mismatch issue will be 
encountered. To solve this problem, the mB4 should perform the 
router portion of IGMP, which is similar to the corresponding MLD 
version (IGMPv2 for MLDvl or IGMPv3 for MLDv2) operating in the IPv6 
domain. Then, the protocol interaction approach specified in 
Section 7 of [RFC3376] can be applied to exchange signaling messages 
with the IPv4 receivers on which the different version of IGMP is 
operating. 


Note that the support of IPv4 SSM requires MLDv2 to be enabled in the 
IPv6 network. 
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